1. Field of the Invention
The present invention relates in general to a multiservice Internet Protocol (IP) network and a method that supports an enhanced QoS message that contains two levels of reservations which makes it possible for IP router(s) to reserve resources for a high priority traffic flow and admit the high priority traffic flow without needing to terminate an existing low priority traffic flow.
2. Description of Related Art
In a multiservice IP network, resource reservation is needed to provide Quality of Service (QoS) for real-time traffic. To address this requirement, the Internet Engineering Task Force (IETF) standardization organization specified the RSVP (Resource Reservation Protocol) signaling protocol. The RSVP signaling protocol is used to make resource reservations in IP routers and is also used to provide integrated services for real-time traffic flows and non real-time traffic flows in the Internet. Following are several documents which describe in detail the RSVP signaling protocol and the Integrated Services architecture:                R. Braden et al., “Resource Reservation Protocol (RSVP)—Version 1 Functional Specification”, RFC 2205, Sep. 1997.        R. Braden, et al., “Integrated Services in the Internet Architecture: an Overview”, RFC 1633, 1994.        J. Wroclawski, “The Use of RSVP with IETF Integrated Services”, RFC 2210, Sep. 1997.The contents of these documents are incorporated by reference herein.        
In a multiservice IP network, the QoS has to be ensured for the real-time traffic flows. As such, before a real-time traffic flow is entered into the multiservice IP network, the RSVP signaling protocol requires that RSVP signaling messages be used to reserve resources in each IP router along a data path that is going to be used to deliver the real-time traffic flow. These resources are identified by a flow ID. If the reservation is successful, then the data flow can be entered into the multiservice IP network.
The RSVP signaling protocol also requires that the per flow reservation states be stored in each IP router along the data path. The reservation states are soft states which means that they need to be refreshed by sending periodic refresh messages. If a reserved state is not refreshed, then the state and the corresponding resources are removed after a time-out period. Reservations can also be removed by an explicit tear down message. The storing and maintaining of per flow reservation states in each IP router can be a problem in large networks, where the number of flows and therefore the number of reservation states is high. The IP routers may not have enough capacity to store and maintain all of these reservation states.
After recognizing this scalability problem, the IETF specified the RSVP aggregation method which allows IP routers to make reservations for aggregated flows. The aggregated reservations are identified by a DiffServ code point (DSCP) and require the storing of one aggregated reservation state which is used for multiple flows in the IP routers. The aggregated reservation state does not need to be created, modified or refreshed for each flow request.
Because, the RSVP aggregation method and several other extensions have been made to the RSVP signaling protocol, the IETF decided to redesign the protocol in the Next Steps In Signaling (NSIS) Working Group (WG). And, even though the scope of NSIS is wider than QoS signaling, one of it's applications is the QoS signaling application. This QoS application is being developed to meet the new signaling requirements of the multiservice IP network. For more details about the NSIS and NSIS QoS application reference is made to the following document:                M. Brunner: Requirements for Signaling Protocols, RFC3726, April 2004.        Hancock, R., “Next Steps in Signaling: Framework”, Internet Draft (work in progress), October 2004.        Bosch, S., Karagiannis, G. and A. McDonald, “NSLP for Quality-of-Service signaling”, Internet Draft (work in progress), October 2004.The contents of this document are incorporated by reference herein.        
The NSIS QoS application signaling protocol, which is currently under specification, is fundamentally similar to the RSVP signaling protocol. For instance, the proposed NSIS QoS application signaling protocol supports most of the extensions that have been made for the RSVP signaling protocol including the RSVP aggregation method.
The multiservice IP network also needs to provide emergency priority services not only for traditional telephony calls but also for other real-time applications like video streams and audio-video conference calls. Even though emergency traffic is high priority traffic, it also needs to have resource reservations made within the IP routers that are on the data path to protect it from background traffic. If there are not enough resources to make the reservation for the high priority traffic, then one or more lower priority reservations have to be pre-emptied so that the higher priority reservation can be accepted. This pre-emption policy is described in detail within the following document:                S. Herzog, “Signaled Preemption Priority Policy Element”, RFC 3181, October 2001.The contents of this document are incorporated by reference herein.        
In view of this pre-emption policy, it can be seen that the current RSVP signaling protocol requires the termination of low priority traffic flow(s) when there are not enough resources for the emergency reservation. This can be a serious problem especially in the case of aggregated reservation when the whole aggregate has to be terminated if there are no free resources for the emergency reservation. Several different devices and methods have been proposed in an attempt to address this problem. One such device and one method and their associated drawbacks are briefly described below.
In one attempt, an adaptive resource broker was used which controlled all of the resources in the multiservice IP network. The adaptive resource broker and a mathematical background of this problem are discussed in the following document:                G. Feher, L. Cselenyi, L. Gefferth: Intelligence Resource Management Agent for Multimedia Teleservices, Proc. Of COST 254 workshop, pp 189-195, Neuchatel, Switzerland, 1999.        
In this adaptive resource broker, the resources assigned to the flows in the network could be aligned adaptively to the network conditions. Unfortunately, this solution has many drawbacks several of which are described next. First, the adaptive resource broker requires information about the whole network, like network topology, traffic matrix etc., which in turn requires additional signaling, or configuration. And, all of this required information is less likely to be available in a multi-domain network. Secondly, the adaptive resource broker may require that an additional node or intelligence be added to the network. Thirdly, the adaptive resource broker is a centralized solution because decisions are made based on more than local information. As a result, the security requirements are demanding and the redundancy of the node has to be solved.
In another attempt, a method has been used to reserve in advance the resources needed for priority traffic. However, this method requires previous knowledge or estimation of the volume of the expected emergency traffic. In addition, this method is not that efficient with the usage of bandwidth because the provisioned resources need to be reserved in time periods when emergency traffic is not going to use those reserved resources. Accordingly, there is and has been a need for a solution that addresses and solves the drawbacks associated with the aforementioned solutions that attempt to reserve resources for a high priority traffic flow without requiring the termination of low priority traffic flows. This need and other needs are addressed by the multiservice IP network, IP router and method of the present invention.